home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Dr. Windows 3
/
dr win3.zip
/
dr win3
/
GRAPHICS
/
WMF2RIP.ZIP
/
WMF2RIP.DOC
next >
Wrap
Text File
|
1993-10-20
|
6KB
|
119 lines
┌──────────────────────────────────────────┐ ┌─────────────────────┐
│ Windows Meta File to RIPScript Converter │ │ Version 0.000000003 │
└──────────────────────────────────────────┘ └─────────────────────┘
This utility will be improved upon and if neccessary, perfected, if someone
out there shows some interest. We'll even think about adding other formats.
Interest can be shown in the following ways:
o A <currency of your choice>20.00 note showing up in our
post-box [WishWare ??!!]
o A post-card from your home town showing up in our post box promising
a <currency of your choice>20.00 note one day if we do finish the
utility, and clearly stating what you'd like to see.
o Even easier .. drop an email message on CIS to Dave Hall [100075,255]
Developed by James Holderness
(c) Vironix Corporation (Pty) Ltd. - May 1993
P.O. Box 1235, Westville, 3630
Republic of South Africa [nope, lions don't roam the streets]
──────────────────────────────────────────────────────────────────────────────
****Major disclaimer****
This utility was written some months ago using the RIP 1.5.1 spec. We
havn't updated it to reflect any changes that could be made with the
1.5.4 spec. The same goes for the documentation below. Our own interest
in this whole RIP thing would probably pick up dramatically if *someone*
would let us in on the RIP 2.0. spec. Hint.
──────────────────────────────────────────────────────────────────────────────
Usage: WMF2RIP source [dest] [options]
Converts SOURCE.WMF to SOURCE.RIP or DEST.RIP.
Since the RIP files produced can get quite big, there are options which allow
the program to merge points that are close together.
The options can be any of the following:
/x??? .... The minimum distance between x coordinates before they are
merged. (default: 4)
/y??? .... The minimum distance between y coordinates before they are
merged. (default: 2)
/m??? .... The minimum number of points a polygon should have before the
merging process takes effect. (default: 100)
/a??? .... The minimum angle in degrees by which the gradient of two
consecutive lines can differ before they are joined to make
one line.
/w ....... This has nothing to do with optimizing the size. It just sets
the background colour to white.
The setting "/m150 /x10 /y7" works fairly well for me, but I haven't used
this much, so you'll probably find you'll need to experiment with each
picture you are converting.
By making the /m setting around 150, you can have the /x and /y settings
fairly high. That way, small polygons used in fonts still keep their detail,
while large polygons which hopefully don't need to be too accurate can get
compressed quite a bit.
Other than the need to keep your RIP files small, the main reason for the
compression is that the current RIP implementations (RIPPAINT and RIPTERM)
are too spastic to handle large polygons. WMF2RIP will warn you if the
polygons produced are fairly big. I'm not sure what the cut off point is,
so sometimes RIP files with warnings will still work, but sometimes they
won't.
You will also find, that only a very few of the WMF commands are
implemented. You will be warned if an unrecognised command is found in
the WMF file.
The palette commands are implemented fairly well as long as the picture
doesn't have too many colours. Once the convertor runs out of colours to
use, it defaults to black. Also, since RIP only supports a palette of 64,
and WMF files can use a palette of 16 million, there are bound to be some
colours that don't look quite right.
From time to time you may get X and Y points that are out of range. You
will get a warning, but the program will do nothing to try and fit them
onto the picture. If they are negative, the RIP picture may screw up,
but if they are too big, the picture should be fine other than that it
is cut off at the edge.
If you are exporting WMF files from Corel Draw, you'll probably find that
the proportion of the picture can get screwed up badly. If you draw a block
around your picture in the proportion of 640x480, it should solve the
problem. Alternatively you can save it with a placeable header (probably
the better solution), although I'm not actually sure if that will work.
One last thing - the RIP files produced are not very well optimized, so you
can probably compress them quite a bit by loading them into RipPaint, using
the optimize option and then saveing them again.
- Jim Holderness, Developer, Vironix
┌───────────────────┐
│ Revision History: │
└───────────────────┘
- Version 0.000000003:
Added support for placeable headers
┌────────────────────────────────────────────────────┐
│ Other toys you can look out for in the near future │
└────────────────────────────────────────────────────┘
"Near future" being an arbitary variable of time.
o Terminal Emulation comms program - just basic stuff with Zmodem
support and *decent* ANSI and RIP emulations.
[Update: the above comment was refering to RIPTerm 1.5.1 ... version
1.5.4 fixes quite a few of the shortcomings thankfully]
Major advantage: will not rely on Borland's BGI Graphics drivers ...
somewhat limiting unfortunately.
o RIP file viewer - better than having to load up RIPaint to admire
your Coreldraw handiwork! (we've done a native Windows version if
anyone is interested in taking a look? If so drop us a note)